The ACPI (Advanced Configuration and Power Interface) specification is an industry standard that combines various methods of power management with various components of “plug and play” functionality for different types of computer systems (e.g., notebooks, desktops, servers, etc.). ACPI is widely supported, with support typically built directly into the operating system. ACPI defines hardware and software interfaces used by the operating system to manipulate the characteristics of system devices (e.g., motherboard devices, low level interfaces, etc.). The specification is intended to be cross platform, wherein the interfaces can be ported to the different hardware configurations of various different hardware platforms (e.g., x86, Itanium, PowerPC, SPARC, etc.). The BIOS/firmware functions by abstracting the specific hardware configuration of a given platform in accordance with the ACPI definitions.
Generally, the ACPI support code provided by the BIOS/firmware is not written in the native assembly language of the platform, but rather in AML (ACPI Machine Language). Except for the few operations performed by an ACPI compliant BIOS/firmware, almost all ACPI operations are performed in the operating system context through the use of an interpreter. The interpreter functions by interpreting machine-independent ACPI Machine Language (AML) byte-code stored in ACPI tables.
AML is usually compiled from human-readable ACPI Source Language (ASL). ACPI Machine Language (AML) is byte-code that the interpreter in the OS context interprets. ACPI Source Language (ASL) is the programming language equivalent for AML. ASL is compiled into AML images. Typically, a hardware vendor writes ASL code and provides the compiled AML code for its hardware in the Definition Blocks of the ACPI System Description Tables of the hardware. At boot time, the BIOS/firmware of the computer system accesses these tables in order to discover the ACPI capabilities of its specific hardware platform.
The industry relies upon a relatively small number of well-known and widely distributed tools for writing ASL and compiling ASL into AML for BIOS/firmware. For example, for x86 based machines and Itanium/IA64 machines, Intel provides tools for interpretation, assembly and disassembly of AML. For Windows-based machines, Microsoft provides the relevant ASUAML tools. Similarly, the AML interpreter in the Linux kernel is implemented in the ACPI4Linux project. Each of these toolsets provides a compiler that compiles ASL modules and routines into corresponding AML code.
A problem exists however, in fact that the well-known, widely used ASL compilers are relatively primitive in comparison to other programming tools for other languages (e.g., C, C++, Java, etc.). There currently exists no support for a number of higher level constructs which are widely implemented in compilers for higher level languages. For example, there is no support in ACPI for object names longer than four characters, and no support for sharing C header files between ACPI and system firmware. There currently exists no support for embedded ASL code that “morphs” at compile time in accordance with certain platform variances, and no support for the inclusion within ASL routines anything that is not an ASL file.
Lack of support for these higher-level constructs renders ASL code much harder to maintain, debug, and develop. The lack of support for these higher level constructs consequently makes ASL files much less reusable, much less portable, and much less shareable, in comparison to other programming languages. These drawbacks make development in ASL expensive and time consuming.
Thus, what is required is a solution that implements high level constructs for ASL development while retaining compatibility with widely supported ASL tools.